Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 100.00%. Comparing base (586b9ca) to head (91dc059).

@@            Coverage Diff            @@
##           develop     #1468   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files          150       149    -1     
  Lines         8399      8394    -5     
  Branches      1951      1950    -1     
=========================================
- Hits          8399      8394    -5     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

• A new set of entries is made into the templateDictionary: one for each item added to a Solution during creation. These entries consist of the item id suffixed with "_type" so that they don't stomp on entries with just the item id. These entries contain the item type and url. For non-Feature Services, the URL is ignored and the id is simply templatized in the Form. For Feature Services, the URL is used to find a templateDictionary entry matching the URL, which is then used for the templatization.

@MikeTschudi, i understood most of what was described here with the exception of above. Could you elaborate on this?

I needed to have a list of item ids that were in the Solution being created so that I could templatize only those ids in Form data (rather than templatizing everything that matches an ArcGIS id pattern). I also needed to know the item type so that I could handle Feature Service URLs (vs. simply templatizing ids).

We currently store some ids in the dictionary, but not all. And the value is an id; replacing it with a structure that included the type and, for Feature Services, the URL broke things in more places than it was worth.

Instead, for each item added to a Solution, I create a dictionary entry in the form <id>_type that contains a small structure: the item's type and its URL. (The URL is only meaningful for Feature Services.)

During Form post-processing, which occurs after all items have been added to the Solution, I extract the <id>_type entries. For non-Feature Services, I templatize the id in the Form data. For Feature Services, I look up the URL in the dictionary, and then replace all occurrences of that URL with its dictionary value in the Form data.

Thanks Mike, I just want to make sure we are not doing something too special for Forms. I believe we have and use this kind of logic on a lot of other item types. For example, I know in Web Maps and Dashboards we do a post process to find references to item ids and feature service urls that might in the data json, but were not explicitly found in our logic to search for dependencies. For example, references in arcade expressions.

My point is this is good logic for all item types, a post process that handles finding item id or feature service url references in items that are apart of the same solution. Our auto discovering of dependencies logic is nice and works well for a lot of item types, but items continue to get more complex and references between items get harder to always account for. This post process logic has seemed to be very safe and reliable for finding and swapping out these references with variables.